The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Internet Protocol (“IP”) telephony using Voice over Internet Protocol (“VoIP”) approaches is gaining widespread use. In IP telephony, spoken words are transformed into a digital representation that is packetized and communicated through a packet-routing network from the calling party to the called party. At a gateway or other network node associated with the called party, packets representing a call are re-assembled, converted from digital to analog form, and audibly presented to the called party.
To prevent unauthorized use of VoIP networks, and to protect VoIP calls against interception by unauthorized parties, secure VoIP protocols are emerging. With a secure VoIP protocol, voice data packets are encrypted at a location near the calling party, transmitted in the network in encrypted form, and decrypted at a location near the called party. An example of a secure VoIP protocol is secure RTP, defined at the time of this writing in an IETF internet-draft, “draft-ietf-avt-srtp-05.txt”.
In some instances, the processor, firmware or software of the called party's IP phone may drop one or more packets of an ongoing packet voice call between a calling party and a called party. The called party's IP phone may determine that packets do not meet certain requirements, in which case the IP phone drops the encrypted data packets. The requirements may vary according to user needs or the capabilities of the IP phone. For example, the IP phone may drop packets because the IP phone cannot authenticate the originating node that sent the data packets.
As a result of an IP phone dropping packets, the party using the IP phone may hear a period of silence, or some other difference in line or voice quality, or may hear no perceivable effect. If silence or a change in line or voice quality occur, the party may believe that the telephone connection is lost, or that a problem exists with the IP phone, in the IP network, or with a service provider that is providing VoIP service. Consequently, the party may hang up the IP phone erroneously, terminating the conversation.
Based upon the foregoing, there is a clear need for providing some form of user notification that indicates a cause of silence or unexpected conditions experienced by a party who is using an IP phone. For example, if the party became aware that authentication failure or other conditions caused a period of silence, then the user might not hang up the IP phone.
Accordingly, there is a need in this field for a way to provide user notification signals in IP phones. There is a particular need for an approach for providing user notification signals in IP phones that use encryption, for example, when the IP phone drops data packets due to authentication failure or other conditions.